1. Field
Embodiments of the present invention generally relate to computer networking. In particular, various embodiments relate to management of a certificate authority (CA) certificate on a client machine and a network security appliance.
2. Description of the Related Art
Many networking applications require secure and authenticated communications. Secure Sockets Layer (SSL) and its related protocols are often used to enable secure communications between a client and a server. According to SSL protocols, session information between an SSL client and an SSL server are negotiated through a handshake phase and the identity of the SSL server is verified by the SSL client. The session information may include a session ID, peer certificates, the cipher specification to be used, the compression algorithm to be used, and shared secrets that are used to generate symmetric cryptographic keys. The SSL client encrypts a premaster secret with a public key from the SSL server's certificate and transmits the premaster secret to the server. Then, both parties compute the master secret locally and derive the session key from it. After the handshake phase, a secure socket is established, and application data encrypted by the session key can be securely transmitted between the client and server.
To inspect data that is encrypted in an SSL packet, a security policy enforcement device may perform SSL man-in-the-middle inspection as shown in FIG. 1. As shown in FIG. 1, a security policy enforcement device (e.g., firewall 120) comprises a kernel 121, a transparent SSL proxy 122 and an inspection module 123. When SSL client 110 initiates an SSL session with SSL server 130 through network 140, a client hello message is transmitted by SSL client 110 though an SSL port, such as port 443. A Transmission Control Protocol (TCP)/Internet Protocol (IP) stack within kernel 121 intercepts the client hello message by monitoring the SSL port. Next, the client hello message is redirected to transparent SSL proxy 122. Transparent SSL proxy 122 uses its own certificate to negotiate with SSL client 110 to setup a first SSL session (“SSL Session 1”). On the other hand, transparent SSL proxy 122 sends a client hello message to SSL server 130 and negotiates with SSL server 130 to setup a second SSL session (“SSL session 2”) over network 150. After the two SSL sessions are established, transparent SSL proxy 122 possesses a session key used for encrypting and decrypting data in SSL session 1 and another session key used for encrypting and decrypting data in SSL session 2. When SSL client 110 transmits data to SSL server 130, data transmitted by SSL client 110 is actually encrypted by the session key negotiated with transparent SSL proxy 122, not SSL server 130. After an encrypted packet that is transmitted from SSL client 110 in SSL session 1 is intercepted by kernel 121, the packet is redirected to transparent SSL proxy 122. Because transparent SSL proxy 122 possesses the session key of SSL session 1, it can decrypt the encrypted packet sent by SSL client 110. After the packet is decrypted, plain data of the packet is sent to inspection module 123 by kernel 121. The plain data is scanned by inspection module 123 according to inspection policies. If the plain data passes the scan, the data is re-encrypted by transparent SSL proxy 122 using a session key that is negotiated between transparent SSL proxy 122 and SSL server 130. A re-encrypted packet is then transmitted by kernel 121 to SSL server 130 through SSL session 2.
During the handshake phase, SSL server 130 sends a server certificate that is issued by a certificate authority and signed by a CA certificate to SSL client 110. SSL client 110 checks trusted root certificates in the certificate store of SSL client 110 for the CA certificate that signed the server certificate. If the CA certificate is one of the trusted root certificates that are installed in the certificate store, it means that the server certificate is signed by a trusted CA and is acceptable to SSL client 110. If the CA certificate is not one of the trusted root certificates, SSL client 110 may present a warning message as shown in FIG. 2 to the user. The user is warned that the security certificate is not issued by a trusted certificate authority and is provided with options to continue or stop establishing the secure connection. If the user decides to continue the secure connection even though the CA is not trusted by SSL client 110, SSL client 110 may temporally accept this CA certificate. Generally, it is not a good practice for the user to accept un-trusted certificates when a warning message is presented.
In a man-in-the-middle SSL inspection system as shown in FIG. 1, transparent SSL proxy 122 establishes SSL session 1 with SSL client 110 and establishes SSL session 2 with SSL server 130 independently. The server certificate sent to SSL client 110 in session 1 is signed by CA certificate of firewall 120. SSL client 110 may show a warning message as shown in FIG. 2 if the CA certificate of firewall 120 is not installed in the certificate store as a trusted root certificate of SSL client 110. To avoid such a warning message, the CA certificate of firewall 120 may be installed manually on SSL client 110 so that the CA certificate of firewall 120 becomes a trusted root certificate of SSL client 110 and no warning message will be presented when encrypted data packets between SSL client 110 and SSL server 130 are inspected by firewall 120.
Manually installing a CA certificate within a firewall requires knowledge of certificates and different operating systems and platform may have different process for installing root CA certificates. It is not convenient for users to install the CA certificate on client systems. Therefore, there is a need for a method and system that automatically installs and manage CA certificates on client systems.